Skip to content

Conversation

@notatallshaw
Copy link
Member

@notatallshaw notatallshaw commented Oct 18, 2025

Closes #6257
Supplants #12717 & #13520 (because I accidentally broke that PR)

Design Choices:

Option Name & Semantics - "uploaded-prior-to" was chosen to match semantically with an exclusive upper bound in both the "date" and "datetime" format, e.g. --uploaded-prior-to 2025-01-01 includes only packages uploaded prior to 2025-01-01 00:00:00 (i.e., 2024 and earlier): #13520 (comment)

Timezone - Accepts ISO 8601 datetime strings, defaults to local timezone if unspecified. Documentation recommends explicit UTC (Z suffix) or UTC offset for reproducibility: #13520 (comment)

Error Handling - Fails immediately if a package index doesn't provide upload-time metadata. File system packages (local directories, wheels, etc.) are unaffected - this only applies to remote indexes: #13520 (comment), so you can specify local packages that depend on remote packages and filter those remote packages by

@notatallshaw
Copy link
Member Author

Okay, this is again ready for review or approval, though I appreciate if no one will have time before 25.3, I will move to 26.0 if it remains unmerged before release.

@notatallshaw notatallshaw modified the milestones: 25.3, 26.0 Oct 23, 2025
Comment on lines +325 to +327
* ``2025-03-16 12:30:00`` - Datetime in local timezone
* ``2025-03-16T12:30:00Z`` - Datetime in UTC
* ``2025-03-16T12:30:00+05:00`` - Datetime in UTC offset
Copy link
Member

@uranusjr uranusjr Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, the space vs T difference is insignificant right? It’s not entirely clear from the examples; if I’m just reading those I’d assume I need to use a space instead of T if I want the local timezone. I’d just use T for all examples and just silently support those not-actually-ISO-8601-compatible formats supported by Python’s fromisoformat.

Comment on lines +14 to +24
def parse_iso_datetime(isodate: str) -> datetime.datetime:
"""Convert an ISO format string to a datetime.
Handles the format 2020-01-22T14:24:01Z (trailing Z)
which is not supported by older versions of fromisoformat.
"""
# Python 3.11+ supports Z suffix natively in fromisoformat
if sys.version_info >= (3, 11):
return datetime.datetime.fromisoformat(isodate)
else:
return datetime.datetime.fromisoformat(isodate.replace("Z", "+00:00"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This introduces a weird edge case

>>> # Note: Python 3.14
>>> import datetime
>>> datetime.datetime.fromisoformat('20220101Z')
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    datetime.datetime.fromisoformat('20220101Z')
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
ValueError: Invalid isoformat string: '20220101Z'
>>> datetime.datetime.fromisoformat('20220101+00:00')
datetime.datetime(2022, 1, 1, 0, 0)

So this non-standard value 20220101Z would parse on older Python but not newer versions. Which is technically fine (it’s non-standard), but might be slightly confusing if the user ever hit it.

Since Python 3.10 is reaching its EOL next year anyway, maybe it wouldn’t be a terrible idea to simply not support Zulu when pip is running on 3.10.x or older.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Install packages up to a certain date

3 participants